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MAKING  COMPUTATIONAL  SENSE  OF 
MONTAGUE'S  INTENSIONAL  LOGIC 


ABSTRACT 

Montague's  difficult  notation  and  complex  model  theory 
have  tended  to  obscure  potential  insights  for  the  computer 
scientist  studying  Natural  Language.   Despite  his  strict 
insistence  on  an  abstract  model-theoretic  interpretation 
for  his  formalism,  we  feel  that  Montague's  work  can  be  related 
to  procedural  semantics  in  a  fairly  direct  way.   A  simplified 
version  of  Montague's  formalism  is  presented,  and  its  key 
concepts  are  explicated  in  terms  of  computational  analogues. 
Several  examples  are  presented  within  Montague's  formalism 
but  with  a  view  toward  developing  a  procedural  interpretation. 
We  provide  a  natural  translation  from  intensional  logic  into 
LISP.   This  allows  one  to  express  the  composition  of  meaning 
in  much  the  way  Montague  does,  using  subtle  patterns  of 
functional  application  to  distribute  the  meanings  of  individual 
words  throughout  a  sentence.   The  paper  discusses  some  of  the 
insights  this  research  has  yielded  on  knowledge  representation 
and  suggests  some  new  ways  of  looking  at  intensionality, 
context,  and  expectation. 
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1 .     INTRODUCTION 

A  worker  in  natural  language  is  likely   to  find  his 
first  encounter  with  Montague  grammar  and  intensional  logic 
a  rather  unsatisfying  experience.   He  finds  that  English 
sentences  are  supposed  to  acquire  meaning  by  being  mapped 
into  a  universe  of  possible  worlds,  of  infinite  sets  and 
functionals  of  functions  on  these  sets.   He  finds,  for 
example,  the  word  "be"  defined  as  a  functional  mapping  a 
function  from  possible  worlds  and  points  in  time  into  entities 
and  a  function  from  possible  worlds  and  points  in  time  into 
functions  from  possible  worlds  and  points  in  time  into  func- 
tionals from  functions  from  possible  worlds  and  points  in 
time  into  entities  into  truth  values  into  truth  values  into 
truth  values.    It  is  difficult  for  him  to  see  how  such  a 
representation  can  help  with  any  of  the  problems  he  faces, 
either  linguistic  problems,  such  as  devising  representations 
for  context  and  expectation  and  algorithms  for  finding  ante- 
cedents of  pronouns  and  resolving  ambiguities,  or  task  problems, 
such  as  question-answering  and  converting  natural  language 
input  into  the  directed  behavior  of  some  device.   In  short, 
he  questions  its  relevance  to  someone  whose  work  and  theory 
must  be  grounded  in  the  need  to  produce  working  computer 
programs . 

In  this  paper,  we  suggest  that  despite  Montague's 
difficult  notation  and  the  complex  model-theoretic  interpre- 
tation for  his  formalism,  there  are  many  potential  insights 
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in  Montague  for  the  computer  linguist.   Montague's  method 
involving  subtle  patterns  of  functional  application,  repre- 
sents an  interesting  way  of  distributing  meanings  of  individual 
words  throughout  a  sentence.   We  show  how  this  method  can  be 
used  computationally  by  relating  Montague's  work  to  procedural 
semantics  in  a  fairly  direct  way.   In  addition,  we  indicate 
how  the  method  might  be  extended  to  handle  certain  aspects 
of  context. 

Much  work  has  been  done  on  Montague  grammar  and  on 
relating  intensional  logic  to  the  semantics  of  English.  We 
will  not  review  this  literature  here.   Rather,  we  will  take 
Montague  [8]   as  the  key  paper  and  representative  of  the 
approach.   Additional  material  can  be  found  in  [9]  and  [11] . 

Montague's  method  for  assigning  meanings  to  English 
sentences  involves  three  distinct  phases.   An  English  string 
is  assigned  a  syntactic  analysis  with  respect  to  a  categorial 
grammar.   This  is  translated  into  an  expression  in  the 
language  of  intensional  logic.   Finally,  this  expression 
undergoes  model-theoretic  interpretation. 

Montague's  language  of  intensional  logic  is  a  typed 
lambda  calculus.   In  this  language  he  constructs  a  generally 
complex  formula  representing  a  pattern  of  composition  and 
application  of  functions,  ultimately  derived  from  the  basic 
terms  of  the  language,  such  terms  as  man,  seek,  run,  etc. 
The  meanings  of  surface  words  are  taken  to  be  very  abstract 
functions,   which  take  as  arguments  other  such  functions. 
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Things  "work  out",  so  that  the  function  assigned  as  the 
meaning  of  a  declarative  sentence  evaluates  at  a  possible 
world  and  point  in  time  to  true  or  false.   Part  of  the 
attraction  of  Montague's  treatment   lies  in  the  way  he 
manages  to  mesh  a  complex  system  of  meaning  assignments  in 
a  mathematically  precise  way  so  that  the  meanings  do  work 
out,  with  the  exact  details  illuminating  some  classic 
problems  of  sem.antics,  including  intensional  predicates  and 
referential  and  nonreferential  terms. 

The  goal  of  any  semantic  theory  is  to  express  English 
strings  in  terms  of  an  "antecedently  understood"  metalanguage 
[11] .   The  metalanguage  of  set  theory  has  been  a  favorite 
choice    this  century.   Meanings  for  Montague  are  ultimately 
abstract  set-theoretic  constructs ,  in  the  tradition  of 
Tarskian  model-theoretic   semantics  [13] .   But  while  these 
constructs  may  be  antecedently  understood  by  humans,  they 
certainly  are  not  antecedently  understood  by  computers,  and 
Montague  makes  no  claim  for  their  being  computable  in  any 
sense. 

To  m.ake  sense  to  the  computer   linguist,  something 
must  be  reduced  to  implementable  procedures.  The  meaning  of 
an  expression  is  then  the  behavior  of  the  procedure  it  is 
transformed  into.   Thus,  while  he  often  uses  formalisms  that 
look  very  much  like  those  of  the  logician,  the  computer 
linguist  is  after  a  quite  different  type  of  semantic  theory, 
one  which  is  ultimately  machine-theoretic  rather  than  rodel- 
theoretic  in  its  orientation  (see  also   Davies  and  Isard  [1] , 
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Isard  [3]  and  Joshi  and  Weischedel  [5]). 

What  guidelines,  then,  can  Mongatue,  the  model-theorist, 
give  the  computer  linguist  in  the  task  of  working  out  the 
details  of  a  procedural  semantics  for  natural  language?  While 
it  is  true  that  Montague's  semantic  constructs  generally 
involve  infinite  sets  and  functions  on  them,  failing  compu- 
tability  on  most  counts,  Montague  has  made  a  significant  contri- 
bution to  the  computational  semanticist  by  showing  possible 
formats  for  the  representation  of   meanings  of  individual 
words  and  mechanisms  for  the  combination  of  meanings  which 
are  considerably  more  elegant  than  most  computational  alterna- 
tives now  in  use.   By  replacing  the  bottom  layer  of  Montague's 
model-theoretic  edifice  with  an  appropriate  set  of  procedures, 
we  hope  to  preserve  computability  while  still  maintaining  the 
basic  framework  of  Montague  grammar.  We  hope  to  convey  those 
aspects  of  Montague  grammar  which  should  be  of  interest  to 
the  artificial  intelligence  researcher  working  on  knowledge 
representation,  and  to  the  computer  linguist  in  particular. 

In  Section  2  we  give  an   outline  of  the  main  features 
of  Montague's  formalism.   In  addition  we  suggest  ways  in  which 
a  computer  scientist  might  think  of  its  key  concepts. 
Section  3  gives  several  Montague-style  examples   together  with 
simple  procedural,  or  machine- theoretic,  interpretations. 
Section  4  describes  the  very  little  that  needs  to  be  done  to 
Montague's  expressions  in  intensional  logic  in  order  that 
they  be  directly  interpretable  as  expressions  in  an  existing 
programming  language,  LISP,  augmented  by  a  small  suitable  set 
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of  primitive  functions.   This  result  then  demonstrates  that 
the  rather  extensive  research  in  Montague  grammar  is  quite 
compatible  with  research  in  procedural  semantics  (e.g.  [15], 
[14]).    Furthermore,  Montague's  very  fruitful  approach  to 
the  problem  of  structuring  functional  —  and  by  extension, 
procedural  —  knowledge  indicates  how  the  method  of  procedural 
semantics  can  be  sharpened  in  just  that  respect  which  has 
caused  it  most  to  come  under  attack:   the  ad  hoc  character 
of  its  definitions.   In  Section  5  we  speculate  on  what  light 
this  approach  may  throw  onto  the  nature  of  context  and 
expectation. 
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2.     MONTAGUE'S  FORMALISM 

This  exposition  will  follow  that  of  Montague  [8]  and 
use  the  more  standard  features  of  his  notation,  but  will 
give  only  those  rules  necessary  for  the  examples  in  this 
paper.   A  few  rules  are  added  to  handle  one  example. 

The  categorial  grammar  used  for  syntactic  analysis  of 
English  strings  consists  of  categories  into  which  English 
words  and  phrases  may  fall  and  rules  for  combining  words  and 
pharses  of  various  categories  into  larger  phrases  and  sentences. 
The  categories,  with  examples  of  words  (or  basic  expressions) 
that  belong  to  them,  are  as  follows: 

Truth  values:       t  (no   basic   expressions) 

Entities:  e  (no  basic  expressions) 

Intransitive  verbs:  IV:  rise,  trot 

Terms:  T:  ninety,  he^ 

Transitive  verbs:    TV:  seek 

Common  noun  phrases:  CN:         man,  frog,  horse, 

temperature 

Adverbials:         lAV:         rapidly 

2 
Attributive  adjectives:  Ad j :      slow. 

Phrases  of  the  various  categories  may  be  built  up  out  of 
basic  expressions  by  the  following  rules  (morphological 
fineries  are  ignored) : 

(1)    (Article  +  Common  Noun  Phrase) .   If  c  is  in  category  CN, 
then  Fq(c),  F^(C)»  F_(c)  are  in  category  T,  where  Fq(c) 
=  every  c  ,  F^{^)    =  the  C/  ^2^^^    =  £  ^• 
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(2)  (Subject  +  Verb  Phrase)  If  a  is  in  category  T  and 
6  is  in  category  IV,  then  F.{a,6)  is  in  category  t, 
where  F. (a,6)  =  a6 . 

(3)  (Transitive  Verb  +  Object)    If  6  is  of  category  TV 
and  8  of  category  T,  then  Fc(6/3)  is  of  category  IV, 
where  Fg(6,6)  =  6&. 

(4)  (Verb  Phrase  +  Adverbial)    If  6  is  of  category  lAV  and 
3  of  category  IV,  then  F_(6,B)  is   of  category  IV, 
where  F_(6,3)  =  66.  (Note:  This  is  the  only  syntactic 
rule  which  reverses  the  order  of  the  elements.) 

(5)  (Attributive  Adjective  +  Common  Noun)    If  6  is  of 
category  Adj  and  3  of  category  CN,  then  F_(6,3)  is   of 
category  CN,  where  F_(6,3)  =  <53. 

(6)  (Conjunction)    If  <i>  ,\l)      are  of  category  t,  then  so  is 
Fg(((),ij^)  where  Fg((l>,t|^)  =  (J)  and  ip . 

(7)  (Quantification)    If  a  is  of  category  T  and  not  he  ; 
and  (fi  is  of  category  t  or  IV  and  contains  he   ,  then 
F, .   («,({))  is  of  the  same  category  as  (f) ,  where 

F,_   (a, 4))  =  ()) '  ,  where  4)'  is  like  cj)  except  that  the 
first  occurrence  of  he   has  been  replaced  by  a. 

This  completes  our  discussion  of  the  syntactic  rules.  We  now 

present  the  language  of  intensional  logic. 

The  basic  types  of  Montague's  intensional  logic  are 

as  follows: 

t  =  truth  values; 

e  =  entities; 

s  =  possible  world  -  point  in  time  pairs. 
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A  possible  world  -  point  in  time  pair  will  be  called  a  point 
of  reference. 

Higher  types  are  built  up  as  follows:   If  a  and  b  are 
types,  then  <a,b>   is  the  type  consisting  of  all  functions 
from  a  to  b.   Expressions  in  intensional  logic  may  be  built 
up  from  constants  and  variables  of  each  type  and  from  other 
expressions  by  means  of  logical  connectives,  quantification, 
temporal  and  modal  operators,  functional  application,  and 
lambda  abstraction.  For  example,  if  u  is  a  variable  and  a  and 
g  are  expressions  of  the  appropriate  type,  then 

a  V  6      (Vu)a  ,   Da,    Xua  ,    a(6) 

are  also  expressions.   In  addition,  if  a  is  an  expression  of 
type  a,  then  ''a  (called  the  intension  of  a)  is  an  expression 
of  type  <s,a>.   If  a  is  an  expression  of  type  <s,a>  then  'a 
(called  the  extension  of  a)  is  an  expression  of  type  a.  The 
extension  operator  *  applies  a  function  whose  domain  is 
points  of  reference  to  the  current  point  of  reference.  The 
intension  operator  ^  applied  to  an  expression  creates  a 
function  whose  domain  is  points  of  reference  and  whose  value 
at  each  point  of  reference  is  the  expression.  (To  reduce 
parenthesizing,  we  assume  ^  and  '  apply  to  the  smallest 
meaningful  expression  to  their  immediate  right.) 

The  types  do  not  occur  arbitrarily  in  the  analysis  of 
English.   Certain  types  turn  out  to  be  the  most  useful,  and 
for  these  key  types  it  is  worthwhile  developing  our  intuitions 
by  describing  computational  analogues.  For  this  purpose,  let 
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us  assuiTie  that  a  point  of  reference  corresponds  to  a  possible 
state  of  the  machine  at  a  particular  mcment  in  time.   Then 
the  extension  of  an  expression  a,  'a  ,  may  be  viewed  as  the 
evaluation  of  that  expression  with  respect  to  the  current 
state  of  the  machine.   The  intension  of  a,   "a  ,  on  the  other 
hand,  represents  an  object  which  when  evaluated  with  respect 
to  any  state  of  the  machine  will  return  the  value  of  a  in 
the  current  state.   In  Section  4  these  notions  will  be  refined, 
and  some  necessary  elaboration  will  be  presented. 

The  type  e  may  be  viewed  as   the  set  of  constants  of  the 
"data  type"  available  in  a  computer    program,  e.g.  numbers. 
Type  <s,e>  is  the  set  of  functions  from  points  of  reference  to 
entities.   When  evaluated,  they  give  an  object  of  type  e, 
a  constant.   Thus,  as  a  first  approximation,  we  may  view  an 
object  of  type  <'s,e>  as  a  simple  variable.   It  associates  a 
constant  with  any  current  state  of  the  machine.   In  particular, 
the  parameter  of  a  procedure  which  evaluates  to  a  constant 
is  of  type  <s,e>.   This  initial  intuition  is  useful,  but  it 
will  have  to  be  modified  somewhat  in  Section  4  below.  In 
addition  the  first  example  of  Section  3  views  objects  of 
type  <s,e>  in  a  slightly  different  light. 

An  object  of  type  <<s,e>,t>  maps  a  variable  into  a 
truth  value  and  thus  may  be  thought  of  as  a  call-by-name 
procedure  of  one  argument  which  returns  a  truth  value.  (This 
will  hereafter  be  called  simply  "a  procedure".)   An  object  of 
type  <s,<<s,e> ,t>> ,   for  any  current  state  of  the  machine 
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evaluates  to  a  procedure,  and  thus  may  be  thought  of  as  a 
procedure  name .   Such  a  name  may  be  attached  to  the  same 
procedure  throughout  the  operation  of  a  program,  or  it  may 
change.   An  object  of  type  <<s,«s,e>,t»,t>  maps  procedure 
najres  into  truth  v.alues  and  thus  may  be  thought  of  as  a 
call-by-name  functional .   Objects  of  type  <s ,<<s,<<s ,e>,t>>,t>> 
are  variables  ranging  over  functionals,  hence  functional  names . 

Predicate  modifiers  like  the  English  word  "rapidly"  are 
realized  as  higher  functionals  of  type  <<s,<<s,e> ,t>>,<<s,e> ,t>> , 
which  maps  procedure  names  (e.g.  the  procedural  interpretation 
of  "walks")  into  procedures  (e.g.  the  procedure  for  "walks 
rapidly") .   Transitive  verbs  such  as  "seek"  and  "be"  are 
realized  as  objects  of  type  <<s,<<s  ,<<s,e> ,t>> ,t>> ,<<s,e> ,t>> . 
This  is  a  higher  functional  taking  two  arguments  —  the  first 
a  functional  name  representing  the  direct  object  of  the  verb, 
the  second  a  simple  variable  representing  the  subject  of  the 
verb. 

In  what  follows,  x,  y,  z  will  be  used  as  variables  ranging 
over  objects  of  type  <s,e>,  simple  variables;  P,  Q,  R  over 
objects  of  type  <s,<<s ,e> ,t>> ,  procedure  names;  and  P  over 
functional  names  of  type  <s,<<s,<<s,e> ,t>>,t>> . 

The  rules  for  translation  from  syntactic  representations 
to  expressions  in  intensional  logic  are  as  follows: 
(1)    The  English  words  "man",  "frog",  "horse",  "temperature", 

"rise",  and  "trot"  are  mapped  into  MAN,  FROG,  HORSE, 

TEMPERATURE,  RISE,  and  TROT,  respectively,  where  these 
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are  objects  of  type  <<s,e>,t>.   For  Montague  they  are 
functions,  i.e.  sets  of  ordered  pairs;  we  may  view  them 
as  the  procedures  in  a  computer  program  which  recognize 
or  define  the  properties  of  "man",  "frog",  etc.  "Slow" 
and  "rapidly"  map  into  SLOW  and  RAPID,  respectively, 
which  are  of  type  <<s,<<s,e> ,t>>,<<s,e> , t>> .  "Seek"  maps 
into  SEEK,  of  type  <<s , <<s,<<s ,e> , t>> , t>> ,<<s ,e> ,t>> . 

(2)  "Be"  maps  into  the  expression  XPXxrPCXyTx  =  'y])]. 

(3)  "Ninety"  is  mapped  into   XPl^PC^n)]   where  n  is  an 
entity  of  type  e. 

(4)  "he."  is  mapped  into  XP['P(x.)]  where  x.  is  the  i^th 
variable  of  type  <s,e>. 

In  the  remaining  rules,  a'  signifies  the  translation 
of  a  under  the  rules. 

(5)  Every  C:  F  (c)  is  mapped  into  XP[(Vx)  (C  '  (x)  ^  'P(x))] 

the  C:  F^(C)  is  mapped  into  XP[(3y)  (  (Vx)  (^  '  (x)  **   x=y)  &  'P(y))] 
a  ?:  F^{c,)    is  mapped  into  XP|(3x)  ( ;  '  (x)  &  'P(x))] 

(6)  F^(6,e)  is  mapped  into  6  •("&') 
F^(6,e)  is  mapped  into  6 '("&') 
F^{6,B)  is  mapped  into  6' ("3") 
F.^{6,B)  is  mapped  into  6'("B') 

(7)  Fg(a,B)  is  mapped  into  a  &  6 

(8)  F,Q   (a,(|))  is  mapped  into  a'{^Xx  ({)')  if  a  is  of 
category  T  and  cj)  of  category  t. 

F,Q  n^*^'*^^  ^^   mapped  into  Xyti '  ("Xx  [6  '  (y)] )  1  if  a  is 
of  category  T  and  6  of  category  IV. 
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Thus,  most  concatenations  of  words  in  English  are  translated 
into  functional  applications  in  intensional  logic. 

Montague  presents  a  standard  irodel-theoretic  interpre- 
tation for  the  expressions  of  intensional  logic.   We  will 
not  outline  the  details,  for  cur  interpretations  will  be 
quite  different.   Objects  in  intensional  logic  will  be 
interpreted  as  constants,  procedures,  and  functionals  in  a 
computer  program. 
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3 .     EXAMPLES 

3.1.   Consider  tha  sentence 

The  temperature  is  ninety  and  the  temperature  rises.  (1) 

This  sentence  has  been  of  interest  [8]  because  if  "be"  is 
viewed  as  equality  and  therefore  as  a  symmetric  and  transi- 
tive relation, 

Ninety  rises 

follows. 

The  syntactic  representation  is 

Fq (F. (Ft  (temperature) ,Fc (be, ninety) ) ,F. (F^  (temperature) ,rise) ) 

O   4   X  J  4    ± 

(2) 
The  translation  rules  map  this  into  the  expression 

XP[(3y^)  ((Vx^)  (TEMPERATURE  (x^)  ^   Xj^=y^)  &  ''P(y^))] 

rXPXx^V?rXY2[''y-2-y2^^^     ('^XQrQ(^n)])) 

&^R[  (373)  (  (Vx^)  (TEMPERATURE  (x^)  ■"•X2=y3)  &  '  R  (y^)  )  ]  ("RISE) 

(3) 

This  expression  can  be  simplified  by  symbolically  applying 
functions  to  their  arguments  in  the  order  indicated  by  (2) 
and  using  the  equivalence  ' ''a  5  a  .   In  the  first  conjunct, 
replacing  P  by  its  value  yields 
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XP[(3yj^)  ((Vx^)  (TEMPERATURE  (Xj^)  **  ^i^Yi^  &"P(yj_))] 
('^Xx2[XQr  QC^n)]  (^Xy2r  X2  ='72!)]) 

Replacing  Q  by  its  value  gives 

XP[(3yj^)  (  (VXj^)  (TEMPERATURE  (Xj^)  ^  ^i^Yi^     &''P(y^))] 
("Xx2[Xy2r  x^  ='y2]  ("n)]) 

Replacing  y^  by  its  value  yields 

XP  [  (3 y^^)  ((VXj^)  (TEMPERATURE  (x^)  **x^=y^)  &  '  P  (yj_)  )  ] 
("Xx2rx2  =  n]) 

Replacing  P  by  its  value  yields 

(3 y3_)  (  (Vx^)  (TEMPERATURE  (x^)  **  x^=y^)  &  Xx2rx2=  n]  (y^^)  ) 
Replacing  x„  by  its  value  results  in 

(3y3^)  (  (Vx^)  (TEMPERATURE  (x^)  ^   ^i=yi)  ^  "Vi    =  J^)   (4) 
(5)  results  from  function  application  in  the  second  conjunct: 

(3y3)  (  (Vx)  (TEMPERATURE  (x)  -"■  x  =y  )  &  RISE(y  ))  (5) 

The  conjunction  of  (4)  and  (5)  reduces  (because  of  the  unique- 
ness of  y)  to 

(3y)  ((Vx)  (TEMPERATURE  (x)  **   x=y)  &  'y  =  n  &  RISE(y)) 

(6) 
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For  our  interpretation  of  (6)  we  will  imagine  a  system 
in  which  the  temperature  is  measured  and  recorded  on  a  graph 
whose  horizontal  axis  is  time.   The  set  of  possible  worlds  is 
the  set  of  all  possible  graphs.   Here   it  is  m.ost  convenient 
to  think  of  y  not  as  a  one-argument  function  from  points  of 
reference  to  numbers  but  as  a  two-argument  function  from 
possible  worlds  and  points  in  time  into  numbers.   Particular- 
ized to  one  possible  world,  it  is  then  a  function  from  points 
of  time  into  numJaers .   The  part  of  (6), 

(3y)  (  (Vx)  (TEMPERATURE  (x)  ■»•  x  =  y)  ...  )  , 

simply  accesses  the  unique  temperature  checking  function.  The 
expression 

'y  =  n 

evaluates  the  function  at  the  current  time  and  returns  TRUE 
if  and  only  if  the  value  is  90.   The  predicate  RISE  computes 
the  left  derivative  of  the  function  y  at  the  current  time; 
it  returns  TRUE  if  that  value  is  positive,  FALSE  otherwise. 

In  a  sense,  this  example  runs  coxinter  to  the  intuition 
developed  in  the  previous  section  about  the  nature  of  objects 
of  type  <s,e>,  such  as  y,  as  simple  variables,  for  here  it  is 
used  as  a  function  from  times  into  nianbers.  However,  a  simple 
variable  itself  iray  be  viewed  as  a  function  from  points  in 
time  into  the  set  of  values  it  takes  on  at  those  given  times. 
The  difference  is  that  in  a  computer  program,  one  is  not  able 
to  access  previous  values  of  a  variable  once  the  value  has 
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been  changed,  as  we  would  have  to  access  previous  values  of 
y  in  this  example  to  compute  its  left  derivative. 

3.2.   Consider  the  sentence 

Every  man  seeks  a  frog. 

By  usual  accounts  it  is  three-ways  ambiguous  —  there  are  the 
intensional  reading   in  which  every  man  is  seeking  something 
which  satisfies  his  own  image  of  "frog"  (reading   1) ,  and  the 
two  extensional  readings  in  which  each  man  is  seeking  his  own 
particular  real  frog  (reading  2)  and  all  men  are  looking  for 
the  same  real  frog  (reading  3) . 

Montague  gives  the  following  syntactic  representations: 


F^(FQ(man),  F^(seek,  F2(frog))) 


F^ (Fq (man) ,F^q  q (F2 (frog) ,F^ (seek,heQ) ) ) 


^10  0 (^2  ^^^°^^ '^4  ^^0  ^^^^^  ,F5 (seek, hep) ) ) 


(reading  1) 
(7) 

(reading  2) 
(8) 

(reading  3) 
(9) 


(7)  translates  into 

XP[(Vx^)  (MAN(x^)  D   'P(x^))]  ("SEEK("XQ[(3y3^)  (FROG(y^) 

&  'Q(y3^))])) 
which  simplifies  to 

(VXj^)  (MAN(x^)  D  SEEK("XQ[(3y3^)  (FROG(y^)&'Q(y^))])  (Xj^)) 

(10) 
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Thus  the  existence  of  the  frog  y,  is  within  the  scope  of  SEEK. 
The  function   XQ  [  (By-j^)  (FROG(y^)  &  'Q(y^))]   will  be  applied 
to  its  argument  within  the  function  SEEK,   y^  stands  for  the 
object  and  Q  will  ultimately  be  replaced  by  the  function 
which  expresses  the  core  of  the  meaning  of  "seek",  in  the 
same  way  as  in  the  previous  example  containing  the  transitive 
verb  "be",  Q  was  replaced  by   Xy- [' x^  =  ''Yt^  * 
(8)  translates  into 

XP[(Vx^)  (M7N(Xj^)  D  ''P{x^))]  ("Xx2[  X Q  [  {3  y ■^)  (F'ROG (Y ^)  ST  Q (y j^)  )  ] 

("XXq[  SEEK('^XRrR(xQ)])  (X2)  ]  )  ]  ) 

which  reduces  to 

(Vx^)  (MAN(x^)  3  (ay^^)  (FROG(y^) 

&   XxpLSEEKC^XRE-RCXp)])  (Xj^)]  (y^)))  (11) 

(9)    translates   into 

XQ[(3y^)  (FROG{y^)     &   '  Q  (y^^)  )  ]  ("Xx^  [Xp  [  (Vx^)  (MAN  (Xj^)^' P  (x^)  )  ] 

("SEEKC^XRrRCxQ)]))]) 

which  simplifies  to 

(ay^^)  (FROG(y^)  &  (Vx^)  (MAN(Xj^)  3  SEEKC'XRT  R(y^)  ]  )  (x^^)  )  ) 

(12) 

In  Montague's  treatment,  sentences  like  "John  is  a  man" 
are  also  syntactically  three-ways  ambiguous,  the  three  readings 
paralleling  (7) ,  (8) ,  and  (9) .   This  is  because  in  the  syntactic 
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analysis,  common  nouns  (category  CN) ,  verb  phrases  (IV),  and 
sentences  (t)  can  all  be  quantified  into.   But  semantically 
they  all  collapse  to  the  same  expression  in  intensional  logic. 

"Be"  is  defined  in  such  a  way  as  to  allov;  the  existential 

4 
quantifier  to  pass  beyond  its  scope.    Also  "John"  introduces 

no  universal  quantifier  to  block  the  existential ' s  passage 

to  the  outside.   The  sentence  "Every  man  is  a  king"  has  two 

readings  in  the  semantics  of  Montague  grammar  —  one  in  which 

every  man  is  a  different  king  and  one  in  which  every  man  is 

the  same  king. 

No  difference  shows  up  in  Montague's  exposition  between 
intensional  verbs  like  "seek"  and   nonintensional  verbs  like 
"see".   It  is  the  responsibility  of  the  one  who  defines  these 
verbs  to  construct  them  in  such  a  way  that  "see"  allows  the 
existential  to  pass  out  of  its  scope  and  "seek"  does  not. 
Montague  has  given  no  guidance  in  the  latter  task.  We  will 
offer  a  suggestion  as  to  how  this  might  be  done. 

A  reasonable  intuitive  operational  paraphrase  of 
"A  seeks  a  frog"  is  "If  a  frog  is  near  A,  then  A  takes  the  frog" 
This  does  not  exhaust  the  meaning  of  "seek",  which  also  has  a 
mental  component:   the  seeker's  intention  as  he  begins  to  seek. 
We  will  confine  ourselves  to  the  oversimplified  operational 
decomposition  of  "seek".   This  will  have  the  shortcomings 
noted  below,  but  it  can  be  used  to  distinguish  between  the 
three  readings  and  has  the  advantage  of  relieving  us,  in  this 
example,  of  the  necessity  of  modeling  mental  states.  The 
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opacity  of  the  verb  "seek"  is  transformed  into  the  opacity 

of  the  conditional  —  ultimately  into  the  opacity  of  negation. 

This  definition  of  "seek"  can  be  captured  within  Montague's 
framework  by  adding  to  the  translation  rules,  paralleling  rule  2 
which  defines  "be",  the  rule 

(2')   "seek"  maps  into  the  expression 

XPXx2[~'P("Ay2[NEAR(x2,y2)  &  -TAKE  (X2  ,y2)  1  )  ]  •        (13) 

The  expression  for  the  object  of  "seek",  which  in  the  inten- 
sional  reading  contains  an  existential  quantifier,  replaces  P. 
The  negation  will  then  be  outside  and  the  propositions 
NEAR(x2,y2)  and  -TAKE (X2 /y2)  within  the  scope  of  the  existential 
quantifier.   The  negation  sign  to  the  left  of  P  in  (13) 
prevents  the  passage  of  the  existential  quantifier  to  the  left. 
It  is  one  of  the  beauties  of  Montague's  approach  that  the 
meaning  of  a  word  can  be  distributed  in  this  fashion.  (10) 
becomes 

(Vx^)  (MAN(x^)  D  XP  [XX2[~''P("Xy2  [NEAR(x2,y2)  &  -TAKE  (x2/y2)  1  )  H 

C^XQLOyj^)  (FROG(y^)  &  'Q(y^))])  (x^)  ) 

or 

(Vxj^)  (MAN(x^)  D    (Vyj^)  (FROG(y^)  D  (NEAR(x^,y^)  3  TAKE  (x^,y^)  )  )  ) 

(14) 
Applying  (13)  to  (11)  yields 

(Vx^)  (MAN(Xj^)  D    Oy^^)  (FROG(y^)  &  (NEAR(x^,y^)  3  TAKE  (x^,y^)  )  )  )  . 
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Applying  (13)  to  (12)  yields 

(By^^)  (FROG(y^)  &  (Vx^)  (MAN  (x^)  3  (NEAR(x^,y^)  3  TAKE  (x^  ,y^)  )  )  ) 

The  three  readings  are  then  distinguished  by  three  different 
quantifier  structures. 

For  our  model  we  can  now  imagine  a  data  base  which 
contains  a  nuir±)er  of  entities  and  a  number  of  properties 
associated  with  these  entities.   In  particular,  it  records 
the  species  of  each  entity  and  for  each  relevant  moment  in 
time,  the  locations  of  the  entities  and  the  facts  about 
possession  of  one  entity  by  another.   Typical  items  in  the 
data  base  might  be 

(MAN  XI)       (FROG  X2) 

(AT  XI  (54  40)  1846)      (AT  Yl  (65  39)  1846) 

(HAVE  XI  Yl  1847) 

A  possible  world  for  this  example  is  a  possible  set  of  such 
entities  and  properties.   The  most  naive  interpretation  of 
the  existential  quantifier  is  a  procedure  which  searches 
through  the  entities  until  it  finds  one  with  the  required 
properties .   The  corresponding  interpretation  of  the  universal 
quantifier  is  a  procedure  which  searches  through  all  the 
entities  to  verify  that  all  have  the  required  properties. 
NEAR  is  defined  in  terms  of  distance.   TAKE  checks  for  a 
change  from  nonpossession   to  possession. 

Although  definition  (13)  distinguishes  between  the 
several  readings ,  it  has  the  disadvantage  that  in  our  model 
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we  cannot  determine  the  truth  or  falsity  of  "Every  man  seeks 
a  frog"   except  after  the  fact,  and  then  (unreliably)  only  if 
the  seeking  was  successful.   For  example,  if  several  men  took 
their  frog  after  being  near  another,  it  must  be  reading  2, 
in  which  each  man  is  looking  for  a  different  real  frog. 
However,  if  only  one  man  came  near  a  frog  and  he  took  it, 
any  of  the  three  readings  may  apply.   Moreover,  if  there  were 
no  such  thing  as  frogs,  the  expression  (14)  would  always  be 
vacuously  true.   We  cannot  hope  to  resolve  these  difficulties 
in  general  without  modeling  mental  states. 

In  addition,  expression  (14)  suffers  somewhat  in  that 
it  does  not  distinguish  between  "Every  man  seeks  a  frog"  and 
"Every  man  seeks  frogs".   This  however  is  due  to  the  fact 
that  a  simple  existential  quantifier  does  not  model  the  meaning 
of  "a"  precisely.   The  intensional  reading  of  the  former 
sentence  implies  linguistically  that  a  m.an  will  stop  after 
finding  one  frog.   But  the  logical  expression 

(3x)  FROG(x) 

does  not  preclude  m.any  frogs. 

Definition  (13)  could  profit  from  the  nicety  of  a  tim.e 
condition  stating  that  the  nearness  was  true  just  before  the 
taking  occurred.  But  these  changes  would  greatly  complicate 
the  exposition  at  the  expense  of  clarity. 
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3.3   Let  us  now  consider  the  sentence 

"A  slow  horse  trots  rapidly." 

with  the  syntactic  structure 

F  .  (F-  (f'  (slow, horse) )  ,F_ (rapidly, trot) )  . 

This  translates  into 

[XP(3x)  (SLOW("HORSE)  (x)  &■  "  P  (x)  )]  ('RAPID  ("TROT)  ) 

which  simplifies  to 

(3x)  (SLOW("HORSE)  (x)  &  RAPID("TROT)  (x)  )  . 

Suppose  we  are  given  an  entity  called  a  "scale"  which, 
for  simplicity,  we  can  think  of  as  an  ordered  pair 
<lo-point ,hi-point> .   Assume  in   addition  that  we  are  given 
two  function  names,  LO  and  HI,  which  are  initially  bound  to 
the  functions  which  map  a  scale  into  its  lo-point  and  hi-point 
respectively.    We  may  then  visualize  the  outlines  of  a 
HORSE  function  as 

HORSE  =  X  X  [  X(...  gallopspeed. . • ) 

[  ...  (speed (x)  >  LO (gallopspeed) ) 
&  (speed (x)  <  HI (gallopspeed) ) 
.  .  .]  (.  .  .<20,35>. . .) ] 

Gallopspeed  may  be  taken  to  be  the  default  speed  scale  for 
HORSE.   A  lambda  application  within  the  definition  of  HORSE 
binds  gallopspeed  to  a  particular  scale  to  which  the  functions 
LO  and  HI  are  applied.   The  verb  TROT  is  handled  similarly: 
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TROT  =  X  X  [  A ( . . .speedscale. . . ) 

[  ... (speed (x)  >  LO (speedscale) ) 
&  (speed (x)  <  HI ( speedscale) ) 
...]  (. ..<14,26>.  ..) ] 

Now  we  can  examine  the  roles  of  SLOW  and  RAPID  as 
mappings  from  intensions  of  objects  like  HORSE  and  TROT 
to  objects  representing  a  slow  horse  and  a  rapid  trotting 
respectively.   SLOW  can  be  defined  as  follows: 

SLOW  =  X  P  [  X  HI[X  X  ['F(x)  ]  ] 

(X  scale  [LO (scale)  +  (HI (scale) -LO (scale) ) /S] ) ] 

Similarly: 
RAPID  =  X  P  [  X  LO[X  X  ['P(x)  ]  ] 

(X  scale [HI (scale)  -  (HI (scale) -LO{scale) ) /3] ) ] 

That  is,  SLOW  redefines  HI  to  return  a  lower  upper  limit  on  a 
speed  scale,  and  RAPID  redefines  LO  to  return  a  higher  lower 
lim.it.   Now  the  meaning  of  "The  slow  horse  trots  rapidly" 
can  be  seen  to  reduce  to 

(3x)  [... (speedy (x)  >  20)  &  (speedy (x)  <  25) 

. . . (speed2(x)  >  22)  &  (speed2  (x)  <  26)  ...]  . 

The  subscripted  function  names,  speedy  and  speed2 ,  had  their 
origin  within  the  scope  of  HORSE  and  TROT  respectively  and 
hence  may  refer  to  the  sam.e  or  different  speed  functions. 
It  is  seen  from  the  final  reduction  that  although  SLOW  and 
RAPID  have  opposite  effects,  the  local  nature  of  the  scopes  of 
HI  and  LO  allow  the  correct  meaning  composition  to  be  obtained, 
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4.     CORRESPONDENCES  WITH  LISP 

4.1.   The  fact  that  Montague  chose  a  lambda  calculus  for  the 
language  of  his  intensional  logic  immediately  suggests  the 
programming  language  LISP  as  the  computational  analogue.  In 
this  section  we  show  how  Montague's  intensional  logic  expres- 
sions can  be  translated  almost  directly  into  LISP  expressions 
which  can  be  evaluated,  or  executed,  in  some  environment  to 
yield  a  result.   Our  analogue  of  intension  will  be  the  procedures, 
Points  of  reference  will  be  incorporated  within  the  environ- 
ment in  which  the  procedures  are  executed,  and  the  results 
will  correspond  to  extensions.   Some  difficulties  naturally 
arise  in  precisely  those  places  where  an  infinite  computation 
seems  to  be   implied  by  Montague's  formalism,  as  in  the  inter- 
pretation of  the  universal  quantifier  over  all  possible 
worlds,  a  clearly  infinite  set   in  most  models.   Our  approach 
has  been  to  replace  infinite  constructions,  usually  "sets", 
by  finite  ones,  such  as  "procedures",  without  destroying  the 
overall  framework  of  functional  composition  and  application 
as  the  basic  method  for  building  up  the  meaning  of  a  sentence. 

Before  proceeding,  we  would  like  to  stress  the  distinction 
between  intension  and  description.   "Description"  refers  to 
a  linguistic  object,  while  "intension"  refers  to  a  function- 
Different  descriptions  may  have  the  same  intension.  Likewise 
we  distinguish  between  a  LISP  function,  which  is  only  applied, 
and  its  various  symiolic  representations  as  s-expressions . 
There  has  been  confusion  on  this  point  in  the  natural  language 
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processing  literature. 

In  the  next  few  paragraphs  we  present  a  brief  discussion 
of  the  relevant  features  of  LISP.   Those  who  find  the  treat- 
ment inadequate  may  consult  McCarthy  et  al.  [6], 

Following  McCarthy  et  al.  [6]  we  view  the  LISP  interpre- 
ter as  consisting  of  two  mutually  recursive  meta- functions: 
apply  and  eval.   The  function  apply  [f;x;a] returns   the 
result  of  applying  function  f  to  arguments  x  in  environment  a; 
eval [e;a]   evaluates  expression  e  in  environment  a.  The  notion 
of  an  environment  was  originally  realized  concretely  as  the 
a-list,  which  pairs  variables  with  their  values.  The  substitu- 
tion semantics  of  the  lambda  calculus  are  captured  in  LISP 
not  by  direct  substitution  into  evaluated  expressions  but 
rather  by  the  creation  of  a  new  environment  which  differs 
from,  that  specified  by  a  in  precisely  those  bindings  which 
define  the  substitution. 

This  method  of  "deferred"  substitution  gives  rise  to 
anomalies  in  the  case  of  functional  arguments  containing  free 
variables.   If  the  same  variables  are  rebound  within  the 
function  calling  the  functional  argument,  the  initial  binding 
of  the  free  variable  m.ay  be  overridden.   These  anomalies  are 
corrected  by  allowing  for  closures,  i.e.  functions  with  frozen 
environments,  to  be  created  by  evel  and  applied  by  apply.  This 
is  done  classically  through  the  use  of  the  operator  FUNCTION 
which  creates  a  closure  or  FUNARG  [6],  [101^   Furthermore, 
it  is  convenient  to  assume  that  the  interpreter  is  such  that 
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eval [ (LAMBDA );a]  is  equivalent  to  eval [ (FUNCTION (LAMBDA ));a]; 

that  is,  a  LAMBDA  expression  evaluates  to  its  closure  (see 
also  [12])  . 

The  simplest  way  to  exhibit  Montague's  formalism  in  LISP 
is  to  identify  a  point  of  reference  with  a  binding  environment, 
or  a-list,  with  respect  to  which  an  expression   is  evaluated. 
Then  we  let  eval [e; a]  correspond  to  the  model- theoretic  inter- 
pretation of  an  expression  e  with  respect  to  a  point  of 
reference.   In  this  view,  the  expression  ^a  corresponds  to 
(LIST (QUOTE  QUOTE)  a) .   It  gives  an  object  to  which  can  be 
applied  the  operator  "  (corresponding  to  EVAL,  the  object 
language  invocation  of  the  m.eta-f unction  eval)  which  in 
turn  yields  an  object  of  the  same  type  as  a. 

The  first  few  translation  rules  are: 

(1)  a,   a  constant  -"(QUOTE  a) 

(2)  a,   a  variable  of  type  <s,b>  for  any  b  -►  (QUOTE  a) 

(3)  "a  -»-( LIST  (QUOTE  QUOTE)  a) 

(4)  '  i  -•-  (EVAL  a) 

In  rule  (2)   the  variable  must  be  quoted  if  the  calling 
function  is  to  be  given  the  option  of  evaluating  or  not 
evaluating  the  variable.   As  a  first  approximation  it  is 
useful  to  look  at  intension  and  extension  as  "QUOTE  the  value" 
and  "EVAL",  respectively,  to  make  firm  some  of  our  intuitions 
about  these  concepts ,  which  behave  formally  in  much  the  same 
way.   For  example,  the  identity 

Interpretation-of  [' ''a]  =  Interpretation  of  [a] 
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is  preserved  in  the  translation: 

eval [ (EVAL (LIST (QUOTE  QUOTE)a));a]  =  eval [a; a] 

for  all  a  and  for  all  a. 

As  appealing  as  this  analogy  is,  however,  it  is  desirable 
to  treat  intension  and  extension  in  another  way,  relating 
reference  points  to  environment  indirectly.  We  may  assvime 
there  is  a  variable  named  *  to  the  value  of  which  intensions 
are  applied  to  produce  the  corresponding  extensions.  We  need 
place  no  restrictions  on  what  *  can  be  bound  to.   For  example  it 
could  be  an  arbitrarily  complex  object  corresposponding  to  a 
model  of  a  possible  world,  implemented  as  a  data  base,  a  list 
of  functions,  or  any  other  suitable  structure.  For  brevity 
we  will  call  the  data  type  of  *  "s-list",  after  the  "s"  in 
Montague's  hierarchy  of  types. 

Now  rules  (l)-(4)  are  replaced  by  rules  (la)-(4a): 

(la)   a,   a  constant    ■*      (QUOTE  a) 

(2a)   a,  a  variable     ■*■     a 

(3a)   "a  ^   (INT*  a)  ,  where 

INT*  =  (LAMBDA (G) 

(LAMBDA (*)  G) ) 

(4a)   'a  ^   (a  *) 

Note  that  here  too  '' ^a  has  the  same  interpretation  as  a,  i.e. 

eval[( (INT*  a)  *) ;a]  =  eval [(( (LAMBDA (G) (LAMBDA (*) G) ) a)  *) ;a] 

=  eval [a; a]  . 

The  remaining  translation  rules  are  the  same  for  either  approach: 
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(5) 
(6) 
(7) 
(8) 
(9) 


Xua 
a(e) 

a  =  e 

-4' 


(10)  4)  V  ij) 

(11)  <i>  ^  i> 

(12)  4)  «»  ij; 

(13)  3U(|> 

(14)  Vu4) 

(15)  D<t> 

(16)  W(J) 

(17)  H4, 


(LAMBDA (U)  a) 

(a  B) 

(EQUAL  a  6) 

(NOT  (f)) 

(AND  (j)  4)) 

(OR  ((>  4^) 

(IMPLIES  4)  4^) 

(IFF  4^  i>) 

(FORSOME  <range  of  u> 

(LAMBDA  (U)  4))) 
(FORALL   <range  of  u> 

(LAMBDA  (U)  4))) 
(NEC  (QUOTE  4,)) 
(FUTURE  (QUOTE  4))) 
(PAST  (QUOTE  4))  ) 


In  rule  (7)  we  have  replaced  true  set- theoretic  equality 
by  the  function  EQUAL  which  tests  for  the  equality  of  symbolic 
expressions.   It  therefore  captures  equality  of  entities  and 
truth  values.   In  the  approach  using  rules  (l)-(4) 

(EQUAL  (QUOTE  a) (QUOTE  3)) 

is  true  iff  a  and  3  are  identical.   This  comes  very  close  to 
capturing  equality  of  simple  variables  (the  highest  type  of 
object  checked  for  equality  in  Montague  [8]).   Two  objects 
of  type  <s,e>  are  equal  iff  they  always  evaluate  to  the  same 
entity.   For  simple  variables  this  could  only  happen  if  they 
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were  identical.   For  the  approach  using  rules  (la) -(4a), 
and  for  objects  of  higher  type  using  either  approach,  EQUAL 
is  not  adequate.   This  highlights  the  need  for  a  deeper 
treatment  of  infinite  objects. 

The  functions  NOT,  AND,  OP,  IMPLIES,  and  IFF  are  self- 
explanatory. 

In  rules  (13)  and  (14) ,  a  naive  extensional  reduction 
of  FORSOME   and  FORALL  would  be  a  procedure  in  which  the 
expression  used  for  the  range  of  u  would  actually  evaluate 
to  a  list.  The  predicate  which  is  the  second  argument  would 
be  applied  to  the  members  of  the  list.   In  a  more  sophisticated 
definition  of  FOPALL  and  FORSOME,   the  range  and  predicate 
arguments  would  be  "models"  or  "descriptors".   FORALL,  for 
example,  would  then  seek  to  prove  that  if  an  element  is  in  the 
range,  the  predicate  is  true  for  that  element. 

In  rules  (15) -(17),  the  reason  that  the  proposition  <j) 
is  quoted  is  that  Montague's  formal  statement  of  the  inter- 
pretation of  the  nodal  and  tense  operators  does  not  call  for 
the  application  of  a  function  to  an  evaluated  proposition, 
but  rather  it  directs  a  different  evaluation  to  take  place. 
In  LISP,  evaluation  m.ust  be  explicitly  blocked,  hence  the 
QUOTE.   Note  that  rule  (6)  does  call  for  evaluation. 

The  procedure  NEC  must  show  that  the  proposition  (J)  is 
true  for  all  possible  worlds.   A  naive  extensional  reduction 
like  that  for  FORALL,  is  not  available  for  NEC  —  we  cannot 
cycle  through  all  possible  a-lists  or  s-lists.   Therefore  we 
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must  use  the  second  method:   NEC  must  show  that  the  set  of 
constraints  which  define  the  possible  worlds  under  considera- 
tion imply  the  truth  of  the  proposition  4).   For  the  operators 
FUTURE  and  PAST  one  could  imagine  interpretations  based  on 
both  proof-theoretic  methods  and  on  extensional  reduction. 

4.2.    In  this  section  we  shall  re-do  the  example  of  Section 
3.1,  show  its  translation  into  a  LISP  program,  and  present 
a  possible,  though  oversimplified,  computational  interpre- 
tation. 

Let  us  suppose  the  translation  of  "temperature"  is  the 
function  TEMP  defined  as  follows: 

(LAMBDA (X) (MEMBER  X  (QUOTE  (TEMP-CHECKERl 

THERM- READER  ...))))  . 

That  is,  TEMP  takes  a  procedure  name  as  its  argument  and 
checks  whether  it  is  one  of  the  known  "temperature-checking" 
procedures.   By  the  rules  given  in  Section  4.1  for  trans- 
lating into  LISP,  "the  tmperature"  becomes: 

(LAMBDA  (P) 

(FORSOME  entity-concepts 
(LAMBDA (Y) 

(FORALL  entity-concepts 
(LAMBDA (X) 

(AND  (IFF  (TEMP  X)  (EQUAL  X  Y)  ) 
((P  *)  Y))))))) 
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(Note  that  we  have  dodged  the  problem  of  checking  equality  of 
functions  by  checking  EQlALity  of  function  names.) 
"Be  ninety"  becomes 

( (LAMBDA (P) 

(LAMBDA  (X)  (  (P  *)  (INT*  ( LA^'B DA  (Y)  (EQUAL  (X  *)  (Y  *))))))) 
(INT*  (LAMBDA (Q) ( (Q  *)(INT*  90))))) 
(FUNARG 

(LAMBDA (X) ( (P  *) (INT*  (LAMBDA (Y) (EQUAL  (X  *) (Y  *)))))) 
( (P  .  (FUNARG 

(LAMBDA (*)  G) 
(  (G  .  (FUNARG 

(LAMBDA(Q) ((Q  *) (INT*  90))) 
NIL))))))) 

The  result  of  applying  the  translation  of  "the  temperature" 
to  the  intension  of  the  translation  of  "be  ninety"  (as  required 
by  the  semantic  rules)  will  be  T  just  in  case  there  is  one 
temperature-checking  function  and  that  function  applied  to 
the  current  *  returns  SO;  otherwise  the  result  will  be  NIL. 
Assuming  appropriate  definitions,  the  cumbersome  lambda  expres- 
sions can  be  replaced  by  atomic  designators.  In  this  case,  the 
form  actually  eval-ed  is: 

((THE  (FUNCTION  TEMP) ) (INT*  (BE  (FUNCTION  NINETY) )) ) 
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5.     CONTEXT  AND  EXPECTATION 

Much  has  been  written  about  the  role  of  context  in  the 
interpretation  of  words  and  sentences.   Frequently  the  context 
is  specified  by  a  natural  language  description  of  any  circum- 
stances, whether  mental,  textual,  or  environmental,  which 
impinge  upon  the  meaning  of  the  item,  in  question  in  any  way. 
However,  it  is  desirable  to  replace  this  by  something  more 
precise.   One  possibility  is  to  view  context  as  the  state 
which  the  initial  conditions  and  previous  text  have  left 
the  text  processor  in.   Thus  a  text  would  serve  as  a  context 
for  a  sentence  exactly  to  the  extent  that  the  state  of  the 
processor  was  altered  during  the  interpretation  of  the 
previous  text. 

Section  4  suggests  a  very  concise  description  of  the 
state  of  a  processor  in  which  the  a-list  plays  a  prominent 
role.   A  complete  state  description  would  contain  control 
information  as  well,  but  for  simplicity  we  will  concentrate 
on  the  a-list.   By  employing  techniques  of  dynamically  bind- 
ing variables  to  valid  function  specifications,  we  can 
circuiTtvent  the  use  of  special,  very  complex  data  structures 
and  still  satisfy  the  dictum  that  knowledge  "com.es  in  large 
chunks" . 

Among  the  proposals  for  handling  contextual  effects  is 
Minsky's  [7]  notion  of  "frames".   A  frame  is  a  large,  complex 
data  structure,  possibly  with  procedures  attached,  which 
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expresses  the  normally  true  general  knowledge  about  stereo- 
typed situations.  When  a  frame  is  accessed,  subsequent 
processing  becomes  a  matter  of  filling  the  slots  and  noting 
the  exceptions.  The  claimed  strengths  of  the  frames  approach 
include  the  existence  of  default  values  for  unspecified 
arguments  and  the  view  of  expectation  as  the  ability  to 
access  pre-stored  relevant  pieces  of  knowledge  efficiently. 
However,  since  frames  as  they  have  been  used  are  amalgams  of 
data  structures  and  arbitrary  procedures,  the  problems  of 
representation  become  heavily  involved  with  issues  of  encoding. 
Furthermore,  it  is  unclear  how  one  gets  into  a  frame,  whether 
one  can  be  in  more  than  one  frame  at  a  time,  how  one  gets  out 
of  a  frame,  how  two  or  more  frames  can  be  mierged  to  under- 
stand novel  texts  and  situations,  etc.   In  short,  these  are 
structures  for  v/hich  there  is  no  well  understood  interpreter. 

By  using  Montague's  functional  approach  to  full  advantage 
one  can  preserve  the  spirit  of  "frames"  while  overcoming  these 
deficiencies.  The  key  is  to  think  of  knowledge  as  residing  in 
functions,  each  of  which  embodies  a  "core  m.eening"  of  a  word 
(or  concept)   embedded  in  a  meaningful  pattern  of  function 
applications,  both  referring  to  the  surrounding  binding 
environment.   In  this  view,  the  "large  chunks  of  knowledge" 
are  accessed  because  when  a  function  is  applied,  it  in  turn 
calls  other  functions.  The  way  that  functions  communicate  is 
by  binding  and  evaluating  variables.   Context  is  the  set  of 
active  bindings,  and  the  contextual  effects  of  one  function 
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on  another  are  expressed  in  the  ways  variables  are  shared 
by  the  functions.   Context  is  changed  when  the  bindings  are 
updated  by  the  application  of  a  lambda  expression  to  its 
arguments.   The  effect  of  updating  the  binding  of  a  function 
on  the  interpretation  of  another  function  may  be  great  or 
small,  depending  on  how  central  or  pervasive  the  first  function 
is  in  the  body  of  the  second.   This  appears  to  us  as  plausible 
and  as  rich  a  method  for  context  switching  with  selective 
override  and  default  as  any  that  have  been  proposed.  The 
method  is  both  subtle  and  fluid.   The  effects  can  be  made 
abrupt  or  slight.   The  creation  of  new  context  goes  on  all 
the  time  without  the   need  for  any  special  context-switching 
mechanism. 

In  order  to  be  more  concrete,  let  us  consider  the 
following  sentences: 

John  approached  Minneapolis.  (16) 

John  approached  maturity.  (17) 

In  (16)  "approach"  is  to  be  interpreted  as  motion  along  a 

scale  of  physical  distances,  in  (17)  a  scale  of  development 

toward  realization  of  some  set  of  properties.  In  Jackendoff's 

[4]  formalism  "approach"  in  (16)  is  in  the  positional  mode, 

in  (17)  in  the  identif icational  mode.   Which  scale  or  mode 

is  relevant  depends  on  the  rest  of  the  sentence,  in  particular 

on  the  direct  object. 

With  Montague- style  patterns  of  functional  application, 

we  can  define  the  words  "approach",  "maturity",  and  "Minneapolis" 

in  the  following  way: 
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approach  =  XP[Axr  P  ("Xz  [  (  3Wj^)  (  3W2) 

(go(x,w,  ,W2,  Scale) 
&  exceed (W2,w^, Scale)  &  HI (Scale) =' z) ])] ] 

maturity  =  XQ  [XScale  [' Q  ('Hi  (Scale) )  ]  (growth-scale)] 

Minneapolis  =  XQ [LOC (Q ("Minn) ) ("Minn)  (18) 

In  the  definition  for  "approach",  "go  (x,Wj^,W2,  Scale)  "  says 
that  x  goes  from  w.  to  W2  on  Scale;  "exceed (W2,w^, Scale) " 
says  that  w^  is  closer  to  the  high  end  of  Scale  than  w.  is; 
"HI  (Scale)  =  "7."    says  that  the  high  end  of  Scale  is  'z. 
In  the  definition  for  "maturity",  "XScale[.  .] (growth-scale) " 
will  bind  Scale  to  growth-scale  within  "approach"  when 
"approach"  is  applied  to  "maturity".   The  core  of  "maturity" 
is  HI (Scale) ;  it  seems  appropriate  to  define  maturity  as 
the  final  point  along  a  scale  of  maturation  rather  than  as 
an  arbitrary  individual  representing  "perfect  maturity". 
The  expression  "approach  maturity"  reduces  to 

Xx[(3w,) (3W2) (go (x,w,,W2, growth-scale)  &  exceed (W2 ,w^ , growth-scale) 
&  HI (growth-scale)  =  HI (growth-scale) ) ] 

In  the  definition  of  ''Minneapolis",  "Minn"  is  an  entity 
corresponding  to  the  individual  Minneapolis.  "LOC"  is  an 
operator  whose  effect  is  to  bring  m  bindings  which  are 
appropriate  by  virtue  of  Minneapolis  being  a  location.  It  is 
one  device  for  encoding  the  "is-a"  or  superset  relation  within 
the  functional  approach.   LOC  is  defined 
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LOC=  Xcore  [Xz  [Ascaier'core]  (distance-scale- toward  (z)  )  ]  ]  . 

When  it  is  applied  within  (18) , 

Minneapolis  =  XQ  [XScale  [' Q  ("Minn)  ]  (distance-scale-toward  CMinn)  )  ] 

results.   Thus,  Scale  is  bound  to  distance-scale- toward  ( ''Minn)  . 
"Approach  Minneapolis"  reduces  to 

Xx [ ( 3w, )  (3w_)  (go  (x,w^ ,Wp ,distance-scale-toward  C^Minn) ) 
&  exceed (w»,w. , distance-scale- toward ("Minn) ) 
&  HI (distance-scale- toward ("Minn) )  =  Minn)] 

Here  contextual  knowledge  is  brought  to  bear  indirectly  by 
the  binding  patterns,  and  the  verb  "approach"  need  not  even 
check  whether  its  object  is  a  physical  location  or  an 
attributed   state. 

The  frames  approach  is  oriented  toward  using  knowledge 
of  the  situation  described  in  the  text,  and  it  seems  to  be 
rather  weak  in  utilizing  the  structure  of  the  text  itself. 
This  may  be  remedied  by  adopting  an  approach  closer  to  the 
one  we  have  described. 

One  of  the  strengths  of  Montague's  approach  is  his  way 
of  attaching  meaning  to  the  intermediate  results,  to  sentence 
fragments.   For  example. 

The  old  overstuffed  chair  in  a  dark  corner  of  the  room    (19) 

at  the  same  time  creates  an  image  and  leaves  the  reader  with 
a  sense  of  expectation.   In  Montague's  approach,  the  image 
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is  captured  by  the  "core  meaning"  of  the  function  corres- 
ponding to  (19) ,  and  the  sense  of  expectation  lies  in  the 
fact  that  the  function  has  not  yet  been  applied  to  its 
argument. 

This  view  of  expectation  as  a  function  waiting  for 
its  argiiment  is  adequate  within  the  boundaries  of  a  sentence. 
But  since  each  sentence  is  of  type  t,  there  is  no  function 
which  is  still  waiting  for  its  argument  intersententially. 
We  might  postulate  that  an  effect  of  a  sentence  with  respect 
to  the  entire  text  is  to  set  up  a  "megafunction"  which  gets 
applied  to  the  similar  megastructures  resulting  from  other 
sentences  in  the  text  in  much  the  same  way  as  an  English  word 
sets  up  a  function  which  gets  applied  to  the  other  words  in 
the  sentence.   For  example,  a  sentence  which  describes  a 
change  of  state  might  be  viewed  as  a  function  which  takes 
sentence  arguments  of  a  certain  type.   Sentences  are  of  this 
type   if  they  presuppose  or  assert  the  final  state  of  the 
change.   This  is  a  very  suggestive  way  of  looking  at  the  notion 
of  expectation.  Whether  it  is  a  fruitful  way  remains  to  be 
seen. 
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FOOTNOTES 


This  sentence  parses  unambiguously. 

2 
This  category  is  not  in  Montague  [8] . 

This  rule  is  not  in  Montague  [8] . 

4 
This  passage  is  equivalent  to  the  operation  "plunking" 

defined  in  Hobbs  [2] . 

In  this  example  we  take  liberty  with  Montague's  formalism 
by  using  certain  variables  in  a  manner  for  which  Montague 
gives  no  formal  interpretation.  This  could  be  remedied  by 
extending  the  definition  of  the  interpretation,  but  this  is 
beyond  our  present  scope.   In  effect,  this  section  anticipates 
the  treatment  given  to  such  variables  in  LISP  examples   to 
be  presented  below. 
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